SoylentNews

Snotnose writes:

What if you posted a famous painting and told people it was AI generated?

A poster wrought some moderate havoc this week when they shared a cropped image of a real Monet painting while claiming it was an AI fake, unleashing a flood of ill-informed reactions and muddled discourse. So, you know, it was just another day online.

"I just generated an image in the style of a Monet painting using AI," read the original post, published to X-formerly-Twitter yesterday by an anonymous conceptual artist who goes by the pseudonym "SHL0MS."

"Please describe, in as much detail as possible," he continued, "what makes this inferior to a real Monet painting."

Commenters were quick to jump in to explain why, in their view, the alleged AI image was worse than the real work of the French impressionist master. According to one, the image was an "incoherent muddle of inconsistently saturated greens." Another lamented that there was no "coherent composition," while someone else shared that the painting seemed "busy, artificial, nature in turmoil, polluted." Another commenter said that the allegedly AI-generated image seemed as if it was "trying too hard" to resemble Monet's later paintings, which he created when he was close to blindness. Others shared that the image was "obvious" AI slop.

[...] As is to be expected, other commenters were quick to dunk on the posters who'd insulted the fake-AI-fake-Monet. Many interpreted the harsh yet ill-informed reaction to the image as an example of "knee-jerk" AI distaste and foolish "AI hysteria."

[...] More than ever before, a lot of the web is fake — a reality that makes it shockingly easy to manipulate actual truth. And in an online world chock full of millions of post-happy armchair experts, insight from genuine experts is perhaps more valuable than ever. Now more than ever: think before you post! Better yet, do a little research before sounding off, or seek insights from informed specialists.

"I think this experiment," commented designer Paul Macgregor, "probably says more about Twitter than it does about AI and art."

Original Submission

Arthur T Knackerbracket writes:

UK folk increasingly don't believe AI jobs revolution will end in prosperity for anyone outside the boardroom, say researchers:

Brits increasingly suspect the AI jobs revolution may end with fewer graduate roles, richer shareholders, and possibly riots.

New research from King's College London found that more than one in five people in the UK believe AI could eliminate jobs quickly enough to trigger civil unrest, as anxiety over automation, hiring freezes, and white-collar displacement continues to bleed out of Silicon Valley boardrooms and into public opinion.

The survey found 69 percent of workers are worried about the economic impact of AI-driven job losses, while 57 percent think the technology will destroy more jobs than it creates. More than half also agreed with Anthropic CEO Dario Amodei's prediction that AI could wipe out half of entry-level white-collar jobs within five years.

University students appeared especially gloomy. Around a third said rapid AI-driven job losses could lead to civil unrest, while 60 percent believe the technology will make the graduate job market significantly tougher by the time they finish university. The study also found that almost nine in ten students who use AI in their studies have already encountered problems with it, including factual errors and completely fabricated sources.

Unlike much of the AI industry's favorite future-of-work PowerPoint optimism, many employers admitted AI-fueled disruption is already happening. The study found 22 percent of employers have already made roles redundant or reduced hiring because of AI, rising to 29 percent among large organizations.

These findings sit in sharp contrast to years of increasingly grand promises from AI vendors about productivity gains and workplace transformation. Earlier this year, analysts predicted AI and automation could erase 10.4 million US jobs by 2030, while another survey found executives increasingly valued human workers less after rolling out AI tools.

Arthur T Knackerbracket writes:

https://arstechnica.com/space/2026/05/the-us-space-enterprise-is-desperately-waiting-for-starship-will-it-finally-deliver/

These days, one would be forgiven for forgetting that SpaceX is, at its core, a rocket company.

Consider the company's mega deals over the last year. SpaceX paid $17 billion—more than it has spent developing every one of its rockets—to EchoStar for wireless spectrum to boost its Starlink network. It revealed plans to launch 1 million orbital data centers. SpaceX merged with xAI in a deal that valued Elon Musk's artificial intelligence firm at $250 billion, and it announced plans to become a major computer chip manufacturer. And earlier this month, SpaceX sold an enormous amount of ground-based compute to Anthropic.

As a result of all this activity, an impending IPO will value the company at something like $1.5 or $2 trillion. That's trillion, with a t.

So yes, one might reasonably ask what SpaceX does these days. Because all the buzz, all the Wall Street euphoria, and all the financial frisson are only tangentially related to what SpaceX cut its teeth on during its first 25 years: becoming the globally dominant player in launch. It largely concerns telecommunications and AI data services.

And yet everything SpaceX aspires to accomplish in the next quarter of a century, all of its enormous valuation, is predicated on a new launch vehicle. A rocket that, to date, has a decidedly mixed record of success. A rocket that has not flown in seven months. A rocket that, finally, may return to the skies on Wednesday.

We are speaking, of course, of Starship—a truly revolutionary rocket. If it works. And after a long period of development and three years of test flights and setbacks, it kind of has to.

[...] Teething challenges notwithstanding, SpaceX is increasingly counting on Starship to be the bedrock of its launch initiatives.

Arthur T Knackerbracket writes:

CFO says GPU rentals are 'structurally higher margin than CPU cloud'

Chinese web giant Baidu has told investors its rare ability to build and operate AI infrastructure at scale represents a new high-margin business that its customers can't avoid.

Speaking on the company's Q1 2026 earnings call, CEO, chairman and co-founder Yanhong Li said GPU cloud revenue increased by 184 percent year-over-year which represented "growth well above the broader market."

CFO Haijian He said that Baidu's GPU cloud "is structurally higher margin than traditional CPU cloud, driven by stronger demand, tighter supply chain, higher technical barriers and pricing power." He added his view that AI applications are "naturally high-margin business, driven by sticky and subscription-based models and operating leverage over time."

Dou Shen, the president of Baidu's AI Cloud Group, remarked "While high-quality supply is relatively tight, customers prioritize proven stability and availability, not just cost."

"For enterprises, it's not only about the peak chip performance," he said. "What matters more is the stability at scale, compatibility with mainstream models and frameworks, migration costs and friction, support for a large-scale cluster deployment and ultimately, cost efficiency."

He thinks the AI market will "increasingly consolidate around players who can deliver on all of these dimensions" and thinks Baidu is nailing them.

[...] Baidu is one of many hyperscalers building its own AI chips and ecosystems, so if the Chinese company's experience is universal the enormous sums of cash US-based clouds are spending on AI infrastructure may well pay off over time.

[...] Baidu's AI revenue numbers remain modest – even the massive growth mentioned above saw its AI cloud revenue reach RMB 8.8 billion ($1.3 billion). But the company was pleased that AI-related products accounted for over half of all revenue for the first time, accounting for RMB 13.6 billion $2 billion) of the quarter's RMB 26 billion take ($3.8 billion).

Without the spike in AI-related sales, Baidu's quarterly revenue would have gone backwards.

Original Submission

An Anonymous Coward writes:

A battle is looming not just over privacy, but the future of the human species.

There will come a time, in the not-so-distant future, when you decide to stick a computer chip in your brain.

At least, that's what D. Scott Phoenix told the audience at TED 2026 in Vancouver last month.

"Someone you work with will get it first. And you'll hold out for a while, the way you did with the smartphone. But eventually, you won't," said Phoenix, dressed in all black with a tiny mic attached to his ear. "The advantages of integration will be hard to compete with."

Put bluntly, in his view, "We're on the cusp of the next major transition, the merger of humans and AI."

This perspective, as outlandish as it may sound, is commonly held in Silicon Valley. OpenAI CEO Sam Altman mused way back in 2017 that "a merge is probably our best-case scenario" for survival after the emergence of superhuman AI. Tech billionaire Peter Thiel is a vocal advocate of "transhumanism."

There is good reason to be skeptical about an imminent evolution for the species. The technology to perform this kind of merger — to radically change what it really means to be human — remains in its earliest stages. Even setting aside the uncertain future of AI, the so-called implantable brain-computer interface (BCI) is still quite nascent.

[...] Ownership of extensive neural data can be used to do anything from serve extremely targeted ads to surveil or manipulate consumers' behavior. The tech billionaires who believe in the possibility of true human-AI integration may also see a chance to make some more money in the meantime.

"If data is the oil of the 21st century," former UNESCO Director-General Audrey Azoulay wrote in November in the Financial Times, "then 'brain' data is the crude oil. We need to guard it more jealously."

Resistance to private sector accumulation of neural data is growing quickly, with red states and blue states alike passing legislation to protect the privacy of neural information.

"fab23" writes:

Coding After AI - Are Humans Still Good Enough for Software Development?:

The last weeks were pretty crazy when it comes to security issues that affect basically everyone. Applications, virtualization stacks like QEMU, CI/CD platforms, operating systems, kernels and even components that were considered stable and trusted for years suddenly became part of critical discussions again.

What makes this wave of vulnerabilities different is not only the technical impact itself. It is the way many of these issues were discovered. Bugs that survived years of reviews, audits, production usage and thousands of developers looking at the same code are now being uncovered within days. In many cases the common factor is artificial intelligence assisted research.

It was honestly not easy to find a proper title for this post because all of them somehow describe the current situation perfectly.

• The Age of AI Vulnerability Discovery Has Begun
• Decades of Trust, Minutes to Break: AI and Modern CVE Discovery
• The End of Human Scale Security Engineering
• Fragnesia, DirtyFrag and Friends: The AI Bug Hunting Explosion

But in the end I ended up with a question instead:

• Programming After AI: Are Humans Still Good Enough?

All of these headlines point to the same uncomfortable reality. Modern software has reached a level of complexity where humans alone may no longer be able to fully understand every corner case, race condition and unexpected interaction hidden deep inside millions of lines of code.

The scary part is that most of these vulnerabilities were not introduced yesterday. Some of them existed silently for years. They lived through releases, rewrites, migrations and security reviews without being noticed. Then suddenly AI assisted analysis enters the picture and starts finding them one after another.

This raises a serious question for the future of software engineering and security research. Are we slowly reaching the point where humans can still build systems, but no longer fully secure them without machine assistance? And if AI becomes better at finding vulnerabilities than humans are at preventing them, what does that mean for the future of secure software development?

For decades software development was primarily driven by humans alone. People learned programming languages, understood algorithms, studied operating systems and network communication, and eventually started building their own applications, libraries and platforms. Every piece of software reflected the knowledge, experience and mindset of the person who created it.

Becoming a skilled developer was never something that happened within weeks or months. It often took years to truly understand how software works internally and how different systems interact with each other. Programming was never only about writing code itself. Developers also had to understand operating systems, APIs, protocols, databases, virtualization, authentication, networking, hardware behavior and many other surrounding components. A good engineer did not only know how to write functions, but also understood the complete environment in which those functions were running.

The quality of code always depended heavily on the capabilities of its author. An experienced developer could write elegant, performant and maintainable code that survived for years with only minimal adjustments. Others produced software that worked, but consumed unnecessary resources, scaled poorly or became difficult to maintain over time. Performance optimizations, memory management and architecture decisions were often directly tied to the knowledge level of the developer.

At the same time humans also introduced mistakes into their own code. Sometimes these mistakes were small and harmless, resulting in minor bugs or unexpected behavior. In other cases they created severe security vulnerabilities that remained hidden for years. A missing boundary check, incorrect assumptions about concurrency, unsafe memory handling or misunderstood access controls could eventually become the foundation for critical security issues.

Software engineering therefore evolved around the principle that reviews would minimize those problems. Developers reviewed each others code, tested changes, discussed implementations and tried to identify weaknesses before software reached production. This process became one of the most important foundations of modern software development. Pull requests, peer reviews, testing pipelines and quality gates were all designed around the assumption that humans are capable of validating the work of other humans.

However, this approach always had natural limitations. A developer who wrote a specific function or subsystem usually understood it very well. The original author remembered why certain decisions were made, which workarounds existed and where edge cases had already been considered. The longer someone worked on the same project, the more the code became an extension of their own thinking.

For external contributors or newcomers the situation was often completely different. Even understanding relatively small functions could already become difficult. Variable names reflected internal assumptions, undocumented dependencies existed between modules and logic paths evolved over years of changes. Code that looked simple at first glance could hide complex interactions that were only understood by the original maintainers.

As projects grew larger this problem scaled dramatically. Modern systems are rarely isolated applications anymore. Today software interacts with APIs, databases, virtualization layers, authentication systems, container runtimes, orchestration platforms, message brokers and external services all at the same time. A single logical mistake in one component can create unexpected side effects across entirely different systems.

This increasing complexity also changed the nature of security issues. Early software bugs were often relatively direct and easy to identify. Modern vulnerabilities frequently emerge from combinations of conditions, timing issues, race conditions or interactions between components that were never expected to communicate in a dangerous way. The famous phrase that software is eating the world also means that software complexity is becoming impossible for single individuals to fully understand.

Another important factor was human exhaustion. Reviewing thousands of lines of code every day is mentally demanding. Developers become tired, deadlines create pressure and companies prioritize feature delivery over perfect engineering. Even highly skilled reviewers can miss critical issues simply because modern code bases exceed human attention spans. Many vulnerabilities that are discovered today are not necessarily hidden because developers were careless, but because the amount of logic and possible execution paths became too large for humans to reason about consistently. So, at this point it doesn't wonder anyone that out of sudden many security issues just came up by AI like Dirtyfrag, Fragnesia, pTrace or QEMU issues and many other ones. The bad thing? Even some of those fixes like Fragnesia were inconsitently fixed where just a bit later some new PoCs (e.g., Fragnesia 2 by v12sec ) raised up.

There was also a strong culture of trust in software engineering. Stable code that survived years in production was often considered safe by default (which is nowadays definately a wrong assumption). Projects with many contributors and large communities created the impression that somebody would eventually notice severe issues. But recent discoveries show that this assumption was overly optimistic. Vulnerabilities can survive years of development, thousands of commits and countless reviews without being detected. All for fair reasons!

At the same time humans also brought creativity and intuition into software development. Developers understood business requirements, made architectural tradeoffs and adapted systems to real world needs. Human engineers were not only writing instructions for computers, they were building abstractions and ecosystems around constantly changing requirements. This creative aspect became one of the greatest strengths of human driven software engineering.

The problem is that creativity alone does not guarantee correctness. As systems became larger and more interconnected, the gap between what humans can build and what humans can completely understand started growing rapidly. For years the industry accepted this as a normal reality. Bugs were expected, patches became part of daily operations and security updates evolved into a permanent lifecycle rather than exceptional events.

Looking back, the past era of software engineering was defined by an important balance. Humans created the systems, humans reviewed the systems and humans tried to secure the systems. The entire process depended on collective experience, collaboration and trust in human reasoning. The question today is whether this model can still scale in a world where software complexity grows faster than human comprehension itself.

CISA Leaves Open Door for Hackers

PiMuNu and Arthur T Knackerbracket write:

https://arstechnica.com/information-technology/2026/05/in-stunning-display-of-stupid-secret-cisa-credentials-found-in-public-github-repo/

Security researcher Brian Krebs brings us the news that America’s Cybersecurity & Infrastructure Agency (CISA) has had a large store of plaintext passwords, SSH private keys, tokens, and “other sensitive CISA assets” exposed in a public GitHub repo since at least November 2025.

The now-offline public repo—named, somewhat aspirationally, “Private-CISA”—was brought to Krebs’ attention by GitGuardian’s Guillaume Valadon, who was alerted to the repo’s presence by GitGuardian’s public code scans. Krebs says that Valadon approached him after receiving no responses from the Private-CISA repo’s owner.

In an email to Krebs, Valadon claimed that the repo’s commit logs show that GitHub’s default protections against committing secrets—protections designed to protect unwitting or unskilled developers against exactly this kind of stupidness—had been disabled by the repo’s administrator.

Testing by Seralys founder Philippe Caturegli showed that this was not a joke or hoax and that he was able to use the credentials in the Private-CISA repo to gain access to multiple Amazon Web Services GovCloud accounts “at a high privilege level.”

Krebs notes that the repo appeared to be managed by Virginia-based Nightwing, a CISA contractor. Nightwing has so far not commented publicly, instead referring questions back to CISA.

This isn’t the first time CISA has screwed up—in fact, it’s not even the first time this year. In January, polygraph-failing acting CISA Director Madhu Gottumukkala uploaded sensitive government documents to ChatGPT after demanding and receiving an exemption to the agency policy that prohibited ChatGPT’s use by CISA personnel. Gottumukkala was removed from his role in February.

America's Top Cyber-Defense Agency Left A GitHub Repo Open With With Passwords, Keys, Tokens – And Incredibly Obvious Filenames

https://www.theregister.com/security/2026/05/19/americas-top-cyber-defense-agency-left-a-github-repo-open-with-with-passwords-keys-tokens-and-incredibly-obvious-filenames/5242915

The US Cybersecurity and Infrastructure Security Agency (CISA) left open a GitHub repository named "Private-CISA" containing plain-text passwords, private keys, tokens, and secrets – with obvious file names like "external-secret-repo-creds.yaml" and "AWS-Workspace-Firefox-Passwords.csv" – for six months.

GitGuardian researcher Guillaume Valadon, fresh off a recent talk on Kubernetes secret leaks, found the public repository on May 14, and told The Register that he "quickly understood that the leak was bad and that time was running out. A national agency having 844 MB of production infrastructure material in a public GitHub repository for six months is as serious as a secrets leak gets." 

Valadon, who previously spent nine years at France's CISA equivalent, ANSSI, told us the leak included tokens for CISA's internal JFrog Artifactory, Azure registry keys, AWS credentials, Kubernetes manifests, ArgoCD application files, Terraform infrastructure code, GitHub personal access tokens, and Entra ID SAML certificates.

GitGuardian reported the leaky repository to CISA on May 14, and the agency took it down a day later. 

A CISA spokesperson told The Register that it was aware of the report and is investigating. "Currently, there is no indication that any sensitive data was compromised as a result of this incident."

It's not a good look for the nation's infosec agency, which hasn't had a permanent boss since Trump took office,  is facing hundreds of millions of dollars in budgets cuts on top of deep cuts to staff and funding last year, and has suffered its share of embarrassing security snafus in the interim.

In a Tuesday blog, Valadon said he initially thought the repo "was a hoax, given how suspicious the directory names (Backup-April-2026/, All Backups/, LZ-Artifactory/, Kubernetes-Important-Yaml-Files/, ENTRA ID - SAML Certificates/ ...), file names (external-secret-repo-creds.yaml, CAWS GitHub Token.txt, Important AWS Tokens.txt, AWS-Workspace-Firefox-Passwords.csv, Kube-Config.txt ...), and their contents (private keys, personal and professional GitHub tokens, AWS secrets, ...) seemed too good to be true," Valadon wrote.

It wasn't a hoax  – "The Cybersecurity and Infrastructure Security Agency is aware of the reported exposure and is continuing to investigate the situation,"  but it was a "catalogue of unsafe practices," he added, containing passwords stored in plain text, backups committed to Git, and an "explicit" how-to guide for disabling GitHub's secret scanning.

After initially reporting the leak through the CERT/CC portal, and only receiving an auto-acknowledgement as of the morning of May 15  – a Friday  – Valadon alerted security journalist Brian Krebs about the publicly exposed secrets, which seemed to speed up CISA's processes. By 6 pm EST that night, the feds took down the repository. 

Valadon told The Reg he gives CISA credit for quickly deleting the repository. "Most of our responsible disclosures take much longer, and many are never fixed," he said. "Managing to take the repository offline in a day is impressive work."

He doesn't know if any other parties with less altruistic intentions found the secrets first, although the fact that the repository was never forked (based on public GitHub events) would seem to indicate that it wasn't widely circulated on the dark web. 

"The only ones that can answer definitively is GitHub," Valadon said. GitHub did not immediately respond to The Register's inquiry.

GitGuardian isn't aware of any of the exposed credentials being abused by unauthorized individuals

"Each category of secret in the repository unlocks a specific attack path," Valadon said. "Stacked together, they cover the full range: from destructive attacks and ransomware extortion to quiet, long-term persistence inside CISA's build and deployment pipeline. That last scenario worried me the most, and it's why I escalated through every channel we had until the repository was taken offline."

Plus, the committer used both a CISA-issued contractor email and a personal Yahoo email across the same commits, and created the repository using a personal GitHub account. "That mixed-identity pattern is one of the hardest surfaces for security teams to cover, and it's where the worst leaks happen," Valadon said.®

Original Submission #1  Original Submission #2 

Arthur T Knackerbracket writes:

At 25, Kurt Gödel proved there can never be a mathematical "theory of everything." Columnist Natalie Wolchover explores the implications:

In 1931, by turning logic on itself, Kurt Gödel proved a pair of theorems that transformed the landscape of knowledge and truth. These "incompleteness theorems" established that no formal system of mathematics — no finite set of rules, or axioms, from which everything is supposed to follow — can ever be complete. There will always be true mathematical statements that don't logically follow from those axioms.

I spent the early weeks of the Covid pandemic learning how the 25-year-old Austrian logician and mathematician did such a thing, and then writing a rundown of his proof in fewer than 2,000 words. (My wife, when I reminded her of this period: "Oh yeah, that time you almost went crazy?" A slight exaggeration.)

But even after grasping the steps of Gödel's proof, I was unsure what to make of his theorems, which are commonly understood as ruling out the possibility of a mathematical "theory of everything." It's not just me. In Gödel's Proof (a classic 1958 book that I heavily relied upon for my account), philosopher Ernest Nagel and mathematician James R. Newman wrote that the meaning of Gödel's theorems "has not been fully fathomed."

Maybe not, but six decades have passed since then. Where are we with these ideas today? Recently, I asked logicians, mathematicians, philosophers, and one physicist to discuss the meaning of incompleteness. They had plenty to say about the implications of Gödel's strange intellectual achievement and how it changed the course of humanity's unending search for truth.

[...]

It is easy to lose one's sense of wonder at the fact that such a blindingly obvious set of axioms — the Peano axioms for arithmetic (the set of rules about the natural numbers 0, 1, 2, 3 ... closely related to the system that Gödel used in his proof, such as the rule, "Every number has a successor") — is essentially incomplete and undecidable, meaning that all axiomatizable consistent extensions are incomplete and undecidable. Hold on to that wonder! The incompleteness theorems teach us that when it comes to our attempt to master the conceptual order, whether it be in mathematics or, for that matter, in any other domain, we will always fail — and indeed, in this case more than any other, we should be glad to have failed, for failure was clearly the more interesting, the more profound, outcome.

Original Submission

An Anonymous Coward writes:

Got an older Kindle? Don't throw it away or rush to upgrade:

Amazon is ending support for older Kindle models on May 20, 2026, but you don't have to grieve your favorite Kindle just yet. With a few simple workarounds (and a couple more advanced ones if you're feeling ambitious), you can keep your Kindle going for years. And if you are ready to move on, there are some solid alternatives worth considering.

Note that you will still be able to read books on discontinued Kindle and Kindle Fire models. But beginning May 20, you won't be able to download new content from the Kindle Store.

[...] Technically, you don't own the books you buy from the Kindle store. What this means is that you're not allowed to transfer or modify those titles. In essence, you're purchasing a license to access the content, which can be revoked at any time. Not only does sideloading make it possible to get content on what Amazon deems an "obsolete" device, but it also lets you own the books you put on your device.

[...] Don't worry, you don't have to steal content from your favorite authors to keep using your Kindle. There are plenty of e-stores where you can buy DRM-free novels legally, such as ebook.com and Smashwords. If you want to try this process for free, public-domain repositories such as the one at Standard Ebooks are a great place to start.

[...] It's possible to untether your Kindle from its Amazon overlord by jailbreaking it, but keep in mind that doing so comes with risks. It's more technical than sideloading and can result in a bricked or otherwise broken Kindle if you run into an issue. Not that it matters for Kindles made before 2013, but it'll probably void your warranty as well. Jailbreaking is a bit of a process and doesn't work for every single Kindle, so make sure to double-check your system version and Kindle model for compatibility before you dive down this rabbit hole.

That said, a jailbroken Kindle can run open-source ebook viewers like KOreader. You'll still have to sideload books, but you'll get much greater control over your Kindle. The platform offers better PDF compatibility, wireless syncing with your Calibre library, and support for more ebook file types without the need to convert them as you do on a non-jailbroken Kindle.

Original Submission

Arthur T Knackerbracket writes:

Data centers are skewing the power supply market, resulting in higher prices for everyone:

Monitoring Analytics, the federally mandated independent watchdog that keeps an eye on the critical PJM Interconnection that distributes power around the U.S., said in a new report [PDF] that a massive 75.5% increase in power costs in the largest region of the U.S. has been directly caused by data centers, and it also blamed the regional market operator for failing to keep up with the rising demand. The price increases have been steep; wholesale electricity prices went up from $77.78 per MWh in the first quarter of 2025 to $136.53 per MWh in the same period of this year.

“The price impacts on customers have been very large and are not reversible,” the watchdog said in the report. “The price impacts will be even larger in the near term unless the issues associated with data center load are addressed in a timely manner, prior to the next BRA (base residual auction), scheduled for June 2026.” Monitoring Analytics says that PJM Interconnection is trying to rewrite the rules for the capacity market and bake in data center demands into its forecasts. The watchdog is critical of this proposal as it will raise the prices for all electricity consumers, putting an unnecessary burden on households and small businesses.

There is a possible solution to this problem: make data centers and other major consumers negotiate directly with power producers instead of mixing that demand with the BRA. This auction is where capacity is sold some three years ahead of when it's needed, and including data center demand in the BRA will push prices up for everyone. In fact, the report says that without the AI infrastructure built out, the PJM Capacity Market would not have seen the high prices we're experiencing now. So, by making data centers negotiate directly with power producers, this will ensure that the expanded capacity is solely shouldered by these large consumers and help keep utility bills stable for everyone else.

However, this is not within the interests of PJM Interconnection. After all, by keeping massive data center loads baked into the general capacity forecast, the power auction would result in higher prices as demand moves up, but supply stays at relatively the same level. This higher cost, in turn, would then be passed on to transmission operators and local utilities, eventually making its way into the bill of the individual consumer.

Arthur T Knackerbracket writes:

New X-rays and CT scans showed small case with locking mechanism containing metal instruments:

Archaeologists used a combination of advanced CT scans and 3D digital reconstruction to identify one of the Pompeii victims who died in 79 CE during the eruption of Mount Vesuvius as most likely having been a Roman doctor, according to an announcement by the Pompeii Archaeological Park.

As previously reported, the eruption of Mount Vesuvius released thermal energy roughly equivalent to 100,000 times the atomic bombs dropped on Hiroshima and Nagasaki at the end of World War II, spewing molten rock, pumice, and hot ash over the cities of Pompeii and Herculaneum in particular. The vast majority of people in Pompeii and Herculaneum—the cities hardest hit—perished from asphyxiation, choking on the thick clouds of noxious gas and ash. But at least some of the Vesuvian victims probably died instantaneously from the intense heat of fast-moving pyroclastic flows, with temperatures high enough to boil brains and explode skulls.

In the 19th century, an archaeologist named Giuseppe Fiorelli figured out how to make casts of those frozen bodies by pouring liquid plaster into the voids where the soft tissue had been. Some 1,000 bodies have been discovered in the ruins, and 104 plaster casts have been preserved. Restoration efforts on 86 of those casts began about 10 years ago, during which researchers took CT scans and X-rays to determine whether complete skeletons were present.

The CT scans and X-ray images revealed that there had been a great deal of manipulation of the casts, depending on the aesthetics of the era in which they were made, including altering some features of the bodies' shapes or adding metal rods to stabilize the cast, as well as frequently removing bones before casting. Ancient DNA analysis in 2024 of four victims found in what is known as the "House of the golden bracelet" revealed that all four bodies were male and none were genetically related—challenging the pre-existing preferred narratives and suggesting those may reflect certain cultural biases.

Arthur T Knackerbracket writes:

Varda hails success of autonomous touchdown tech and celebrates heat data haul:

American outfit Varda Space Industries thinks it's a little closer to operating factories in space after successfully landing its latest test craft.

Varda won the USA's first-ever license to first license fly uncrewed spacecraft that reenter the Earth's atmosphere. The company wants to do this so it can build small craft that include manufacturing facilities that create products it's only possible to make in microgravity - mostly pharmaceuticals - and figures that the relatively cheap launch services offered by private launch companies will make orbital factories economically viable.

Spacecraft are not cheap to build, and the cost rises if they include equipment to slow from orbital speeds before reaching Earth's atmosphere. Crewed craft can be more expensive still. And humanity just doesn't have a lot of capacity to schlep stuff home from space.

In March, Varda therefore launched a capsule called the W-6 that it hoped would survive re-entry at hypersonic speeds, and do so using an autonomous navigation system "that uses onboard imagery to identify resident space objects, including stars and low Earth orbit satellites, to determine precise vehicle position."

The company reckons that represents "a critical step toward fully autonomous navigation for hypersonic and reentry vehicles."

The craft also carried one nose tile that included samples of advanced thermal protection materials, another two tiles equipped with sensors to record data NASA will use to learn about hypersonic re-entry and the materials that make it possible.

Thermal performance matters because if you go to all the trouble of launching an orbiting factory if the product made in space gets cooked during re-entry.

It all seems to have worked because the capsule touched down as planned on Monday.

Varda hasn't said much about the state of the W-6's capsule and its interior when it landed but has celebrated the flight as "another demonstration that frequent, low-cost, reliable return is easily accessible."

The W-6 landed at the Koonibba Test Range in South Australia, whose operator Southern Launch celebrated the fact this is the fourth capsule to land in the patch of remote bushland it tends in the last twelve months.

See also: FAA to Require Reentry Vehicles Licensed Before Launch

Original Submission

Arthur T Knackerbracket writes:

Older Intel 7-based processors are locked up for servers and industrial use, leaving OEMs with little choice:

Intel 7 still underpins a large portion of Intel’s product line, from consumer notebook and desktop CPUs like Raptor Lake to Xeon 6 “Granite Rapids” server processors. As AI-driven demand for data center CPUs surged through 2025, Intel deliberately shifted Intel 7 wafer starts toward its Data Center and AI group, where Xeon parts can bring higher ASPs and better margins.

CFO David Zinsner confirmed as much during Intel’s Q3 earnings call last October, when he said capacity constraints on Intel 7 and 10 had limited the company’s ability to meet demand across both data center and client products. Intel currently has no plans to expand Intel 7 capacity.

Another exec described placing an order for 100 Intel 7 processors and receiving just 30, with 10 of those being unrequested 18A-based chips. “We were told if we don't take the 18A CPUs, they would be given to other PC makers.” Intel, in a statement to Nikkei Asia, described its Core Series 3 processors as “integral” to its client strategy but didn’t confirm whether it is actively steering clients toward 18A adoption.

Many PC makers had originally built only a handful of 18A-based models to support Intel's launch rather than in response to consumer demand, the report claims. "Frankly speaking, PC makers designed a few models based on 18A last year mainly as a favor to Intel, as the chip is expensive and the market demand is relatively small because it is too premium," another source reportedly said.

According to this report, that’s now changed, however, as OEMs that want CPU allocation are effectively being forced to redesign more of their lineups around the newer, pricier silicon. These designs, per one executive, will take “at least three months” to complete and verify, and the shift to premium CPUs also forces upgrades to displays, sensors, and other components to justify the price tag. Wildcat Lake launched barely a month ago, meaning Intel is asking OEMs to commit volume to a product family with almost no commercial track record.

[...] Counterpoint Research analyst Brady Wang said that demand continues to outpace supply, and that some of that pressure may be offset by weakening PC demand overall. Some in the industry expect a year-on-year decline of more than 15% as component costs rise.

Original Submission

liar writes:

https://www.npr.org/2026/05/18/nx-s1-5822366/musk-altman-openai-jury-verdict-claims-dismissed

A jury in California took less than two hours to decide that Elon Musk waited too long to file a lawsuit against his one-time business partner Sam Altman over the direction he's steered the artificial intelligence company OpenAI since the two had a falling out nearly a decade ago.

In a unanimous decision, the nine-member advisory jury said Musk was beyond the statute of limitations when he launched his case in 2024. Judge Yvonne Gonzalez Rogers, of the U.S. District Court for the Northern District of California, agreed, tossing the case out."

[...] In determining that the suit was filed too late, the jury sidestepped questions at the heart of Musk's case accusing Altman and co-founder Greg Brockman of committing a "breach of charitable trust" by allegedly jettisoning OpenAI's founding mission, and then profiting from the decision — claims they disputed in court.

Original Submission

Arthur T Knackerbracket writes:

https://www.zdnet.com/article/microsoft-releases-its-first-server-linux-distribution-azure-linux-4-0/

Microsoft has released Linux-based programs before. The first was the Azure Sphere edge computing device. This was followed by CBL-Mariner, a Linux-based container software platform, which was later renamed Azure Linux. Never, however, had Microsoft released a general-purpose Linux distro, until now.

That was it. That was all he said. Zemlin called him back onstage and asked if he'd really just announced a Microsoft Linux distro. Burns replied that yes, he had. Zemlin continued, "When Microsoft joined the Linux Foundation, there was this big conspiracy theory that somehow the Linux Foundation was undermining open source in partnership with Microsoft, and now you announce that you're shipping a Linux distribution. That's amazing."

He's right. It is. We've come a long way from the days when former Microsoft CEO Steve Ballmer called Linux a cancer. Now, Burns said, "It's been a really great journey, and it's been awesome to see everybody within the company rally around it."

So why did the news catch us all by surprise? It was because the news was originally meant to be announced at Microsoft Techcon in two weeks. But, at the last minute, Microsoft decided to let the news out now.

Burns left the conference before I could get further details, but the Linux Foundation's crack PR team arranged for me to meet Lachlan Everson, Microsoft's principal program manager on Azure's open-source team. He told me Microsoft is turning Azure Linux into a full-fledged general-purpose cloud distribution with Azure Linux 4.0 while simultaneously productizing Flatcar Container Linux as a hardened, immutable container host called Azure Container Linux (ACL).

The former is a general-purpose virtual machine (VM) image for all Azure customers, not just Azure Kubernetes Service (AKS) users. Until now, Everson noted, "we had Azure Linux only available to third-party customers through AKS specifically, and that was Azure Linux 3.0." Going forward, this will be ACL.

Everson emphasized that Azure Linux 4.0 is the culmination of years of internal usage and the evolution of the earlier Mariner distribution. "So we've been running Azure Linux for many years internally, and we got through to 3.0, and we only allowed it on as a container host on AKS. What we've done is make it a general-purpose, so this is all the learnings that we've had in the heritage of Mariner."

Under the hood, Azure Linux 4.0 is based on Fedora Linux and is delivered as an open distribution on GitHub. This code is available now. Yes, Red Hat knows that Microsoft has done this. Everson continued, "So, we made a decision to use Fedora as an upstream, so it's using RPMs in the Fedora ecosystem. Microsoft curates the packages and the supply chain to fit Azure's cloud platform." Microsoft also created "it to be purpose-built for Azure, which integrates vertically into all of our infrastructure to give you the best Azure Linux experience on Azure."

While Azure Linux will ship as a VM image, Microsoft is already preparing a developer-friendly path onto Windows desktops: "And as of today, we have it as a VM image for your VM host on Azure. We're going to announce WSL images as well."